Conventionally, online commerce services designed to accept orders for merchandise using the Internet have been available. In these online commerce services, service providers prepare Web servers. Users access the Web servers prepared by the service providers through the Internet using client computers on which Web browsers are installed, and perform e-commerce transactions by ordering merchandise and making payments.
In some case, a Web server is implemented by sharing processing associated with such an e-commerce transaction between an application server computer and a database server computer. In this specification, however, in addition to such server computers, an apparatus or an overall system which provides a predetermined service or implements predetermined processing by exchanging data with a client computer equipped with a Web browser in accordance with HTTP (Hyper Text Transfer Protocol) will be called Web servers.
The Web browser installed on a client computer used by a user is not designed to be connected to a specific Web server, and operates independently of any Web server. For this reason, a Web server can rarely know the state on the Web browser (for example, which screen is displayed on the display of a client computer).
A Web browser is provided with functions like “back” and “forward” which are used to access Web pages, displayed in the past, in chronological order, and a function of opening a new window of which contents is the same as that of a window which has been focused (e.g., “open this page in new window” function). These functions are implemented when the Web browser uses data cached in the storage unit of the client computer. Therefore, the Web browser makes no new request to the Web server. This makes it more difficult for the Web server to know which kind of Web page is displayed on the Web browser.
In addition, the existence of various types of Web browsers which operate differently makes the situation more complicated. Consider, for example, the execution of the function “back”. In this case, some Web browsers generate no new requests to Web servers which display pages while other Web browsers do generate requests. In addition, even when the windows displayed on displays are changed in size, some Web browsers generate new requests to Web servers.
In such an environment in which various types of Web browsers coexist, problems may occur when a proprietary function of a specific Web browser is used. That is, the data transmitted by a user from a Web browser may become inconsistent with the data stored in a Web server as a result of this transmission (or the processing intended by the user may become inconsistent with the processing result obtained by the Web server).
A specific example in which the state on the Web server side becomes inconsistent with the state on the Web browser side of a client computer will be described below with reference to FIGS. 11 and 12.
FIG. 11 is a view schematically showing changes in screens displayed on a Web server which provides a online commerce service and on a Web browser connected to the Web server.
Screens B1101 to B1104 are examples of screens displayed on the Web browser by the exchange of data between the Web server and the Web browser along with the progress of a transaction. The screens B1101 to B1104 are identical to the screens shown in enlargement in FIGS. 3 to 6 (to be described later), respectively.
When a user selects a product by pressing a purchase button P302 for the product displayed in the product selection screen B1101 (FIG. 3) (This indicates pressing a button on a GUI by, for example, clicking a pointing device or pressing the “Enter” key on a keyboard. The same applies to the following description), the Web browser generates a request to the URL assigned to the purchase button P302.
An instance D1101 on the Web server corresponding to this URL issues a unique session ID, and generates an instance D1102 in the memory of the Web server. At this time, the session ID issued by the instance D1101 is stored in member variable session_id of the instance D1102. The instance D1102 transmits the orderer input screen B1102 (FIG. 4) to the Web browser.
The user inputs his/her name and address to text fields P401 and P402 with, for example, the keyboard, and presses an “OK” button P404. In response to this operation, the Web browser generates a request with the information of the name and address to the URL assigned to the “OK” button P404.
The instance D1102 is associated with this URL. The instance D1102 receives the information of the address and name, and performs processing like that shown in the flowchart of FIG. 12.
The instance D1102 stores the name in member variable name, and the address in member variable address (S1201). In addition, an instance D1103 is generated (S1202). The newly generated instance D1103 is stored in member variable next of the instance D1102 (S1203). The same data as those of the instance D1102 are stored in member variables session_id, name, and address of the instance D1103 (S1206).
The instance D1102 is stored in member variable prev of the instance D1103 (S1207). The instance D1103 transmits the input information confirmation screen B1103 (FIG. 5) to the Web browser (S1208).
When the user presses a “confirm” button P504 upon confirming a name P501 and address P502 displayed in the confirmation screen B1103, the Web browser generates a request to the URL which is associated with the “confirm” button P504. The instance D1103 is associated with this URL. The instance D1103 stores order content and the name and address of the orderer in a DB (database), and instructs the Web browser to redirect them to a screen B1101a (FIG. 3).
When an error occurs at the time of storing values in member variables or a DB, an instance D1104 is newly generated, and the error display screen B1104 (FIG. 6) is transmitted to the Web browser. Although an error code (err001) is displayed in P601 of the screen B1104, a message which is easy for the user to understand may be displayed. Instead of dynamic display of an error code, a static error page (remaining the same regardless of error contents) may be displayed. In this case, the instance D1104 does not exist, transition to the screen B1104 as a static page is made by redirecting using the function of the Web browser.
When a “back” button P505 is provided for the confirmation screen B1103 (FIG. 5) independently of the “back” function of the Web browser, member variable prev is needed in the instance D1103. When the button P505 is pressed, it is possible to transmit the preceding input screen B1102 to the Web browser by using the instance D1102 stored in member variable prev.
Likewise, member variable next exists in the instance D1102. When the user presses the “OK” button P404 in the re-displayed input screen B1102, the instance D1102 can acquire the instance D1103 by using member variable next, set member variables name and address of the instance D1103, and transmit the screen B1103 to the Web browser. This makes it possible for the Web server to quickly implement screen transition without generating any new instance for each screen transition and suppress the memory consumption to a low level.
Note that in the above case, the product selection screens (B1101 and B1101a) are static pages. However, the following problems arise even if the screens B1101 and B1101a are dynamic pages. In addition, in the above case, a description of screens associated with payment such as a credit card number input screen is omitted. But the following problems arise in such screens.
Note that in practice, it is general to separately prepare a screen for inputting a quantity and delivery destination by preparing a member variable indicating a product and a member variable for storing a quantity and transferring a product ID and the like from the instance D1101 instead of generating an instance specialized for a product as in this case.
Note that in this case, a session ID is generated in the instance D1101 and is stored in the member session_id of the instances D1102 and D1103. Containing the session ID in the URL and associating the instances D1102 and D1103 with the URL make it possible to suppress the memory consumption due to screen transition and allow a plurality of users to purchase identical products at the same time. Such a technique of maintaining one process in the form of session is currently generally used. Generally, a Web server which requires login issues a session ID to each Web browser at the time of login and maintains the session until logout or timeout.
The process described with reference to FIGS. 11 and 12 is a simplified example of a process conventionally used for online commerce. In this process, when a function of Web browsers is used, the Web server cannot know the state of the Web browser. Consequently, the operation performed by the user with the Web browser may become inconsistent with the resultant data stored in the Web server.
A case wherein the following inconsistency occurs will be described below.
Assume that in the above process, the orderer input screen B1102 is being displayed on the Web browser, and the orderer input screen B1102 is being displayed in a window A01 of the Web browser. Assume that the user checks the URL of the orderer input screen B1102, opens another Web browser, and let the newly opened Web browser display the same URL. Assume that this new window is denoted by reference symbol A02.
As a consequence, the identical orderer input screens B1102 are displayed in the different windows, i.e., the windows A01 and A02. Since the screens B1102 displayed in the two windows A01 and A02 are associated with the same URL, identical screens are displayed.
Note that the Web server can be designed to make transition to an error screen upon receiving two or more requests for the same URL, thereby inhibiting the Web browser from displaying identical screens. As described above, however, some Web browser generates a request to the same URL even when only the size of a displayed window is changed. This makes it impossible to perform such control to prevent the generation of repetitive requests to the same URL.
When, first of all, the user inputs his/her name and address through the orderer input screen B1102 displayed in the window A01 and presses the “OK” button P404, the Web server performs the processing in steps S1201 to S1208 shown in FIG. 12 described above. As a result, the name and addresses are respectively stored in member variables name and addresses in each of the instances D1102 and D1103, and the input confirmation screen B1103 is displayed in the window A01. The name and address displayed in the input confirmation screen B1103 are input through the input screen B1102 displayed in the window A01.
Subsequently, the user inputs his/her name and address through the window A02 in which the orderer input screen B1102 is being displayed, and presses the “OK” button P404 in the screen B1102. The windows A01 and A02 are each associated with the same instances D1102 and D1103. For this reason, the name and address input through the screen in the window A02 are overwritten on member variables name and address in each of the instances D1102 and D1103. The screen B1103 is displayed in the window A02. The name and address displayed here are input through the screen B1102 in the window A02.
In this state, the contents displayed in the input confirmation screen B1103 displayed in the window A01 are not updated. Therefore, the data input through the window A01 (the data before being overwritten by the data input through the window A02) is kept displayed. Even if the user trusts the display in the window A01 and presses the “confirm” button P504, the instance D1103 stores a value different from that recognized by the user in the DB. More specifically, the name and address input through the orderer input screen B1102 displayed in the window A02, overwritten on member variables name and addresses of the instance D1103, are stored in the DB.
When the “confirm” button P504 in the input confirmation screen B1103 displayed in the window A02 is pressed, the name and address input through the window B1102 are stored in the DB in the same manner as described above. Even if a customer intends to make different orders by inputting different names and addresses through the windows A01 and A02, the orderer information input later is stored in the DB. As a consequence, two identical orders are generated.